In case the CI test results are private, the error for Python 3.13 is:

  ___________________________ test_default_src_is_set ____________________________
  csp/tests/test_utils.py:62: in test_default_src_is_set
      policy_eq("default-src example.com example2.com", policy)
  csp/tests/test_utils.py:11: in policy_eq
      assert parts_a == parts_b, f"{a!r} != {b!r}"
  E   AssertionError: 'default-src example.com example2.com' != 'default-src example2.com example.com'
  E   assert ['default-src...example2.com'] == ['default-src... example.com']
  E     
  E     At index 0 diff: 'default-src example.com example2.com' != 'default-src example2.com example.com'
  E     
  E     Full diff:
  E       [
  E     -     'default-src example2.com example.com',
  E     +     'default-src example.com example2.com',
  E       ]

After some thought, I'm slightly negative on this PR. Looking at the Django settings reference, I can't find any settings that use a set but instead use a list and default to an empty list []. Looking further, there is code that raises an exception if certain settings are not a list or tuple. This matters because our goal is to get some version of this code into Django. If they have a policy of non converting set settings values, maybe we should as well, and leave it to the user to convert them as they'd like (list(set_value), or even list(sorted(set_value)))

After some thought, I'm slightly negative on this PR. Looking at the Django settings reference, I can't find any settings that use a set but instead use a list and default to an empty list []. Looking further, there is code that raises an exception if certain settings are not a list or tuple. This matters because our goal is to get some version of this code into Django. If they have a policy of non converting set settings values, maybe we should as well, and leave it to the user to convert them as they'd like (list(set_value), or even list(sorted(set_value)))

To me, it seems unpythonic to force the value to be a list or tuple, when really all we need is any Collection[str]. It'd only make sense to me to constrain it more than that in cases where ordering is significant—like Django's middleware or installed apps settings. In this case, CSP rules are by-spec not ordered. And sending duplicate values (what using sets aims to prevent) does have a real user impact due to wasting bandwidth.

To me, it seems unpythonic to force the value to be a list or tuple, when really all we need is any Collection[str]. It'd only make sense to me to constrain it more than that in cases where ordering is significant—like Django's middleware or installed apps settings. In this case, CSP rules are by-spec not ordered. And sending duplicate values (what using sets aims to prevent) does have a real user impact due to wasting bandwidth.

Thanks for continuing to engage on this PR. Yes, I think I'm proposing Sequence[str], because it makes testing easier. Allowing set does avoid duplicates, perhaps leading to a better experience for django-csp users. It does add an additional burden on the django-csp devs, but that's how trade-offs work.

In Mozilla's bedrock, a set is used to ensure there are no duplicates, and then converted to a list to make django-csp happy:

https://github.com/mozilla/bedrock/blob/a092ffcd9d17c641cac1426fa4b1f9f7dae06f07/bedrock/settings/__init__.py#L87-L96

In Mozilla's fx-private-relay (where I'm a maintainer), a lot of code is used to append new items to lists and avoid duplicates:

https://github.com/mozilla/fx-private-relay/blob/a76e8c37ad19ef7e8d9133cdd7a0ccacfd1d1d15/privaterelay/settings.py#L109-L227

Using a set signals that the developer doesn't care about order. However, the tests do care, since we don't parse the generated header but just do a string compare. My suggestion is to convert any set to an alpha-sorted list, to enforce a consistent and testable order, and combine better with sequences. This would involve some more code in build_policy in csp/utils.py, something like:

        if v is not None:
            v = copy.copy(v)
            if isinstance(v, set):
                v = sorted(v)
            if not isinstance(v, (list, tuple)):
                v = (v,)
            csp[k] = v

This would be needed on both the config and update passes.

This way, we've got all ordered sequences when we get down to the end of build_policy. You could probably remove the line with dict.fromkeys to preserve order, and avoid the subtle change in Python 3.13.

Ok, I've incorporated some of those notes, but kept the duduplication logic at the end. That prevents duplicate values from creeping in if the same value is supplied twice, once by normal settings and once by an update decorator.

Are you able to see details of failing tests? If not, I can copy them.

Are you able to see details of failing tests? If not, I can copy them.

I can see them, but seems like an erroneous failure. The error is due to ruff formatting:

csp/tests/test_templatetags.py::ruff::format Would reformat: csp/tests/test_templatetags.py
FAILED

But, I didn't change that file. When I try to reformat it by running using the version of ruff I already had installed, there was no change to the file. I had to update ruff from 0.8 -> 0.9 before it would change anything. IOW, it's only failing due to the ruff version not being pinned. Regardless, I'll push a fix in a couple minutes.